@TimoPtr can you please have a look on it? you have additional webview PRs ... maybe there's conflict between the PRs ...

Also check what is happening when having arguments in the url like some filtered on the history page.

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

Thanks for the thorough review @TimoPtr! I've addressed your feedback:

Duplicate path retrieval: Removed getCurrentWebViewPath() from the Activity — the Presenter already handles this fallback in collectUrlStateChanges(), so the Activity now only passes the intentPath (or null).

intent.removeExtra(EXTRA_PATH): Moved before presenter.load() so the extra is consumed immediately.

moreInfoEntity assignment: Fixed the behavioral change — removed the unconditional raw assignment. Now only sets moreInfoEntity to the regex-validated entity for older servers (JS dispatch path), and explicitly clears it when using the URL path approach (>= 2025.6).

Exception handling in getCurrentWebViewPath(): Removed the broad catch (Exception) — Uri.parse() is lenient and doesn't throw, so the try-catch was unnecessary.

Path extraction simplification: Replaced with webView.url?.toUri()?.path?.takeIf { it.length > 1 } as suggested.

Comment reference: Updated to use the full GitHub issue URL.

Regarding URL arguments (e.g. filters on the history page): Uri.path only returns the path component and excludes query parameters, so filtered views like /history?entity_id=sensor.foo will correctly preserve just /history as the path — the frontend will reload with its default state for that view, which is the expected behavior when switching between internal/external URLs.

Regarding URL arguments (e.g. filters on the history page): Uri.path only returns the path component and excludes query parameters, so filtered views like /history?entity_id=sensor.foo will correctly preserve just /history as the path — the frontend will reload with its default state for that view, which is the expected behavior when switching between internal/external URLs.

Actually it might be nice to keep the whole URI and just change the host/port imagine you are on
http://192.168.15.6:8123/history?start_date=2026-02-19T11%3A00%3A00.000Z&end_date=2026-02-19T14%3A00%3A00.000Z

It would be nice to only change the host/port 192.168.15.6:8123 to the other URL to keep exactly where you are.

The issue would be that most probably you are going to loose the history and if it is not the case I wonder what happens. Did you try to play with the app to see how it behaves for the history?

Changes

1. Preserve full relative URL on network switches (WebViewPresenterImpl.kt, WebView.kt, WebViewActivity.kt)

Added getCurrentWebViewRelativeUrl() which extracts the full relative URL (path + query parameters + fragment) from the current WebView URL, stripping the external_auth parameter since the presenter re-adds it on every load.
In collectUrlStateChanges, subsequent urlFlow emissions now read the current WebView URL instead of only using the initial path parameter. This ensures the user stays on the exact same page (e.g. /history?entity_id=...&start_date=...) after a network switch.

2. Clear WebView history on base URL changes (WebViewPresenterImpl.kt)

Added lastBaseUrl tracking in collectUrlStateChanges to detect when the base URL changes (internal ↔ external).
When a base URL change is detected, isNewServer is set to true, which triggers keepHistory = false and clears the WebView's navigation history. This prevents the back button from navigating to unreachable URLs from the old connection.

3. Safe back navigation after URL switches (WebViewActivity.kt)

After history is cleared, rapid urlFlow emissions can create stale history entries from the old connection. The back button handler now validates the origin of the previous history entry using WebBackForwardList before navigating back.
If the previous entry has a different origin (stale entry), the handler navigates to the base URL instead of attempting to load an unreachable page.
If the user is already on the root path, back exits the app as expected.
doUpdateVisitedHistory keeps the back callback enabled when on a non-root path, so pressing back navigates to root before exiting.

Tested:

WiFi → mobile data switch on Lovelace tabs: URL switches correctly, page preserved
WiFi → mobile data switch on history page with query parameters (/history?entity_id=...&start_date=...): page and filters preserved
Mobile data → WiFi switch: same behavior, page preserved
Back button after switch: navigates to base URL (no "cannot connect" error)
Back button on base URL: exits app correctly
Multiple rapid switches: no infinite loading loops

@TimoPtr all tests are successfully done. Do you have any hints?

Let's wait for @jpelgrom final review before merging this. Also I would like to wait that the current release is on the play store before merging this one.

Did you already test the feature? On my side everything works as expected. I tested it for some days in my productive environment.

Let's wait for @jpelgrom final review before merging this. Also I would like to wait that the current release is on the play store before merging this one.

Did you already test the feature? On my side everything works as expected. I tested it for some days in my productive environment.

I honestly didn't because I don't have a test setup with internal/external URL. I want to test this once it's merged because we have an internal lane on the play store. I focused on the code itself for now.

The switching now mostly works from a technical point of view and preserves the URL when switching between networks on the same server, and doesn't when switching servers.

However I have two issues:

1. I never seem to get the 'predictive back animations' anymore, both with the very simple app start>dashboard loads>swipe to go back and variations with more navigation and/or switching networks. Did you test this?

2. I still find the back behavior 'inserting' a root page after switching networks with a non-root path very odd. This also causes a behavior change for shortcuts which deeplink to a specific dashboard: previously that dashboard was the root (which in this case is correct) so pressing back closes the app - now it adds the / page and requires one more back.

Before:

After (this also shows the animation issue):

(I'm using energy as an example as I'm not that much into dashboards myself, but you can imagine people having shortcuts to specific dashboards and/or views who get this extra step now.)

I've spent some time thinking about a solution for the keepHistory issue.
My proposal is to keep a separate logical back stack alongside the native one, so we don't depend on the WebView history surviving the switch.

Logic:

• New WebViewNavigationState holder with logicalBack: ArrayDeque<String>
  and currentLogicalPath: String
• doUpdateVisitedHistory pushes only when the path component changes.
  This filters out the HA frontend replaceState calls (e.g.
  /history?entity_id=...&start_date=...). Cross-origin URLs and reloads
  are skipped, native history handles those.
• Base URL change: keep the logical stack, load newBaseUrl + currentLogicalPath,
  then clearHistory(). On isNewServer: also clear the logical stack.
• resolveBackAction order: canGoBack() -> GoBack, else
  logicalBack.isNotEmpty() -> GoBackLogical(path), else None.
  NavigateToRoot goes away.
• enabled exposed as StateFlow<Boolean> from the holder, the activity
  collects it. State is correct before the gesture starts.

Fixes both points:

1. Predictive back works again because enabled updates synchronously
   from the flow, not inside doUpdateVisitedHistory after the load.
2. Deeplink to /lovelace/energy starts with empty logicalBack and
   currentLogicalPath = "/lovelace/energy", so back closes the app
   directly without the extra / step.

Touched files: new WebViewNavigationState.kt, BackAction.kt (drop
NavigateToRoot, add GoBackLogical), WebViewPresenterImpl.kt (hook
collectUrlStateChanges into the holder), WebViewActivity.kt (collect
the flow, route doUpdateVisitedHistory and back callback through the
holder). Holder is plain Kotlin without view dependencies, so the Compose
rewrite in #6386 can reuse it as-is.

If the direction works for you I'll prepare the changes.

• doUpdateVisitedHistory

I'm not a big fan to try to keep a secondary history. Especially that if you are deep into the app and switch URL each back would reload the app because the origin would be different, so showing the loader every back.

I invite you to join the discord discussion with the product people to decide where to go with this. Since it's mostly a UX question not really technical.

Even with the latest changes, predictive back doesn't work at all in my testing. Likely because the history doesn't start with / but that shouldn't matter, my initial dashboard isn't at / and even the default is at /home/overview now.

My WebView has decided to start doing native crashes when changing network somewhat regularly, making testing quite inconvenient. It does seem that when it doesn't crash it is never inserting a navigation to the default dashboard anymore though.

Pushed three commits addressing predictive-back end-to-end (both code paths):

1. 4cfa569 - Enable Android 14+ predictive-back by gating back handlers on canGoBack
   Hoist canGoBack state from HAWebView to the caller (FrontendViewModel /ConnectionViewModel), driven by a new onCanGoBackChanged hook in HAWebViewClient. The internal BackHandler is now only enabled when the WebView has back-stack entries - otherwise the gesture falls through to the system and the peek animation works. Same change for the legacy WebViewActivity (drops the hasNonRootPath() fallback in doUpdateVisitedHistory).

2. 63bcc74 - Clear navigation back-stack after onboarding completes
   navigateToFrontend() was pushing FrontendRoute on top of the finished OnboardingRoute, so back from the frontend popped to an empty (white) onboarding screen instead of exiting. Fixed with popUpTo(0) { inclusive = true }.

3. 2d8c946 - Clear WebView history after transitioning out of about:blank
   The WebView accumulated every URL loaded, including the about:blank placeholder for Loading /Error / SecurityLevel states. Pressing back from the root walked back into a white about:blank screen. HAWebViewClient.onPageFinished now calls webView.clearHistory() once it detects the transition BLANK_URL → real URL. SPA pushState is unaffected.

Tested on Android 16 emulator (API 36.1), gesture navigation, both code paths:

Legacy WebViewActivity (USE_FRONTEND_V2 = false): predictive-back works on root, normal webView.goBack() inside the app.
Compose FrontendScreen (USE_FRONTEND_V2 = BuildConfig.DEBUG): same - back through SPA history, then peek + exit cleanly from root, and reopening the app lands on the dashboard.